\documentclass{article}

\usepackage[top=2.5cm, bottom=2.5cm, left=2cm, right=2cm]{geometry}
\usepackage{fancyhdr}
\lhead{\bsc{Programmation Orientee Objet}}
\rhead{\bsc{TD4}}
\renewcommand{\headrulewidth}{1px}
\lfoot{ \bsc{Enseirb-Matmeca}}
\rfoot{ \bsc{Informatique - I2}}
\renewcommand{\footrulewidth}{1px}
\pagestyle{fancy}
\usepackage{wrapfig}
\usepackage{multicol}
\usepackage{textcomp}
\usepackage[T1]{fontenc}
\usepackage{setspace}
\usepackage{graphicx} 

%\usepackage[vlined,lined,boxed,french,longend]{algorithm2e}

\usepackage{graphicx}
\usepackage[french]{babel}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{mathrsfs}
\usepackage{xcolor}
\usepackage[utf8]{inputenc}
%%%%%%%%%%%%%%%% Variables %%%%%%%%%%%%%%%%
\def\projet{2}
\def\titre{Lot 2: Des nouveaux caractères d'usagers \\
  --------------------- \\Substitution d'objets}
\def\groupe{2}
\def\equipe{piyovimoad}
\def\responsible{mmegzari}
\def\tandemi{avilliermet, vpomier}
\def\tandemii{ydubernet, ppocquetduhautjusse}

\begin{document}
%%%%%%%%%%%%%%%% Header %%%%%%%%%%%%%%%%
\noindent\begin{minipage}{\textwidth}
\vskip 0mm
\noindent
    { \begin{tabular}{p{7.5cm}}
        {\bfseries \sffamily
          Rapport du TD n°4 de l'équipe \equipe}
        \begin{center}{\itshape \titre}\end{center}
    \end{tabular}}
    \hfill 
    \fbox{\begin{tabular}{l}
        {~\hfill \bfseries \sffamily 23/10/12 \hspace{1.5mm} \hfill~} \\[2mm] 
        Coordinateur : \responsible \\
        Tandem1 : \tandemi \\
        Tandem2 : \tandemii
    \end{tabular}}
    \vskip 4mm ~

    \parbox{\textwidth}{\small \textit{Travail restant à la fin de la séance~:}

Il restait la fin de la partie 1 (à  partir de 1-3 question 3), ainsi que toutes les parties 2 et 3.
}

    \vskip 1mm ~
\end{minipage}




%%%%%%%%%%%%%%%% Main part %%%%%%%%%%%%%%%%
\section{Introduction}
L'objectif de ce TD était d'utiliser des relations entre classes afin de permettre l'ajout de nouveaux caractères d'usagers sans avoir à modifier le code des classes existantes, et ainsi pouvoir diminuer la dépendance existante entre les différentes classes. Les relations entre classes utilisées sont les relations de \emph{type/sous-type}.

\section{Programmer avec des abstractions}
Dans le TD précédent on a remarqué une grande dépendance entre la classe \texttt{PassagerStandard} et la classe \texttt{Autobus}. Alors que \texttt{PassagerStandard} n'est qu'une réalisation particulière par rapport à \texttt{Autobus} et vice-versa. Donc, l'introduction des nouveaux caractères d'usagers ne pourra pas être prise en compte sans modifications entre ces deux classes.
\\


Pour éviter ces dépendances inappropriées, il nous est proposé d'introduire deux interfaces \textt{Bus} et \texttt{Passager} et à l'aide de la relation de \emph{type/sous-type} faire une substitution d'objets. Ces deux interfaces sont des abstractions, dont les classes concrètes \texttt{PassagerStandard} et \texttt{Autobus}, ainsi que leurs versions faussaires sont des réalisations.
\\

La relation de \emph{type/sous-type} dans un language typé, permet grandement la factorisation du code. En effet, l'implémentation de quelques particularités d'une classe implique l'ajout d'une nouvelle classe et donc d'un nouveau type, ainsi on est obligé de créer une autre version de toutes les classes clientes qui manipulent cette nouvelle classe. Pour éviter cela, la relation de \emph{type/sous-type} nous permet de définir des abstractions et des classes de base qui regroupent les comportements communs entre les différentes classes particulières. De plus, la relation de \emph{type/sous-type} permet de diminuer les dépendances entre classes et ainsi contribue au respect de l'encapsulation. 






\section{Remaniement du code}
\subsection{Remaniement des classes PassagerStandard et Autobus}
Les interfaces créées : \texttt{Bus} et \texttt{Passager}, contiennent toutes les déclarations des méthodes spécifiées dans la documentation des deux classes, qui seront alors des méthodes abstraites et seront réalisés par les classes qui implementent ces interfaces. Il n'est pas nécessaire de déclarer la méthode \textt{toString()}, vu qu'elle est héritée de la classe objet, et donc elle est déjà définie sur toutes les instances de ces classes. Toutefois, sa redéfinition permet de simuler un comportment particulier suivant le type de l'instance.
\\

Une fois les interfaces crées, il a fallu déclarer et implémenter la relation de \emph{type/sous-type} entre les classes et les deux interfaces. Cette relation est un héritage entre classe et interface caractérisé par le mot clé \emph{implements}. Donc la déclaration de la classe \texttt{PassagerStandard} devient :\\
\texttt{public class PassagerStandard implements Passager}. 
\\

Ensuite, on remplace toutes les variables et instances de \texttt{PassagerStandard} dans \texttt{Autobus} par \texttt{Passager} et vice-versa. De ce fait, on a annulé toute dépendance entre les deux classes. 
 
\subsection{Remaniement des tests unitaires}
Les deux classes faussaires ne sont que des réalisations particulières de \texttt{Passager} et \texttt{Bus}, donc il est évident qu'il faut définir une relation de \emph{type/sous-type} entre ces classes faussaires et les deux interfaces introduites auparavant. Cette relation va permettre de résoudre le conflict de nom entre la version faussaire et la version concrète et de définir une autre classe dont l'utilité est de tester l'interaction de la classe concrête avec celle dont elle est dépendante.
\\

Ainsi, on procède aux modification suivantes : 
\begin{itemize}
\item Changement des nom des classes faussaires : \texttt{PassagerStandard} devient \texttt{FauxPassager}.
\item Implémentation de la relation de \emph{type/sous-type} à l'aide du mot-clé \texttt{implements} : \texttt{class FauxPassager implements Passager}.
\item Modification des prototypes des méthodes en substituant les paramètres de type \texttt{PassagerStandard} et \texttt{Autobus} par \texttt{Passager} et \texttt{Bus}.
\item Modification des tests pour prendre en compte la nouvelle réalisation des faussaires (nom de class et constructeur).
\end{itemize}

\\ 


Il est à présent possible de fusionner le répertoire source avec celui des tests et de définir une unique méthode \texttt{LancerTests}. On dispose bien de cinq classes publiques au paquetage que sont : \texttt{Passager, Bus, PassagerStandard, Autobus et LancerTests}.

Le diagramme de classe de ce remaniement est :

%inclure le diagramme de classe
\begin{figure}[!h]
\begin{center} 
\includegraphics[width=10cm]{diagramme1.png}
\caption{Diagramme de classe du remaniement}
\end{center}
\label{diagramme1} 
\end{figure} 



\section{Portée et dépendance de compilation}
A ce stade, toutes les méthodes d'instance des deux classes \texttt{PassagerStandard} et \texttt{Autobus} sont disponnibles dans les deux interfaces \texttt{Passager} et \texttt{Bus}. Parmi ces méthodes, figurent des méthodes internes au paquetage et ne devant pas être accessibles de la part du client. De plus, la compilation des interfaces \texttt{Bus} et \texttt{Passager} imposera une recompilation de la classe client même si elle n'utilise pas ces modifications.

\\

Afin d'annuler ces dépendances, il nous est proposé de séparer les méthodes utilisées par le client des méthodes internes dans deux nouvelles interfaces \texttt{Usager} et \texttt{Transport}.

\\

Une autre solution envisageable serait de remplacer l'interface par une classe abstraite et ainsi déclarer les bonnes portées. Certes, cette solution permet de régler le problème de visibilité des méthodes internes depuis la classe client, mais elle ne résout pas les problèmes de dépendances de compilation. En effet une modification des méthodes internes entraînera une recompilation de la classe abstraite, ce qui imposera toujours une recompilation de la classe client. 

\subsection{Remaniement du code}

Comme durant tout le TD le remaniement s'est fait en parallèle entre les deux tandems.


Le travail à faire se résume à:
\begin{itemize}
\item Dans les nouvelles interfaces \texttt{Usager} et \texttt{Transport}, on regroupe toutes les méthodes qui doivent être accessibles au client. Puis on met l'interface en \texttt{public} pour qu'elle soit accessible depuis la classe client.
\item Les interfaces \texttt{Passager} et \texttt{Bus} deviennent de portée \emph{paquetage} et contiennent toutes les méthodes des classes concrètes.
\item On implémente un autre lien \emph{est-un} entre la version concrète, la version faussaire et la nouvelle interface à l'aide du mot-clé \texttt{implements}.

\end{itemize}

\\

Dans le code de la méthode \texttt{monterDans(Transport t)}, il est nécessaire d'effectuer la conversion \texttt{Bus b = (Bus) t}, vu que le paramètre est de type \texttt{Transport} et les seuls envois de messages possibles sont ceux disponnibles dans l'interface \texttt{Transport}, même si ce paramètre contient une instance de \texttt{Autobus} lorsque la méthode \texttt{monterDans} est déclenché par le client. Donc, sans la conversion, l'envoi des messages : \texttt{demanderPlaceAssise() et demanderPlaceDebout()} n'est pas autorisé.

\\

Après toutes ces manipulations visant à restreindre l'accès du client aux méthodes internes des classes \texttt{PassagerStandard} et \texttt{Autobus}, il est toujours possible d'y accéder. En effet, les classes \texttt{PassagerStandard} et \texttt{Autobus} sont déclarées en \texttt{public} pour qu'elles puissent être instanciées dans la classe client. De plus, les méthodes internes à ces classes sont aussi déclarées en \texttt{public} pour avoir une cohérence avec l'utilisation des interfaces \texttt{Bus} et \texttt{Passager}. Ainsi, la classe client à un accès direct à ces méthodes et aux deux classes \texttt{PassagerStandard} et \texttt{Autobus}. 

\section{Les classes concrètes}
Pour résoudre le problème de portée précédent deux solutions différentes ont été implémentées :

\subsection{Classe Concrète publique}
La première solution envisagée consiste à laisser les classes concrètes \texttt{PassagerStandard} et \texttt{Autobus} de portée \texttt{public} pour pouvoir les instancier dans la classe client. Par contre, pour pourvoir interdire l'accès aux méthodes internes depuis la classe client, on remplace les interfaces \texttt{Bus} et \texttt{Passager} en classes abstraites avec une portée \texttt{package}. Puis on suit le schéma de modifications suivant :
\begin{itemize}
\item On rend toutes les méthodes internes aux deux classes visibles dans le paquetage \emph{tec} en supprimant le mot-clé \texttt{public}.
\item Dans les classes abstraites \texttt{Bus} et \texttt{Passager}, on déclare toutes les méthodes en \texttt{abstract} vu que leurs réalisations figurent dans les sous-classes.
\end{itemize}

Ce changement de réalisation donne lieu au diagramme de classe suivant :
\newpage

%diagramme de classe solution publique
\begin{figure}[!h]
\begin{center} 
\includegraphics[width=10cm]{diagramme2.png}
\caption{Diagramme de classe de la solution publique}
\end{center}
\label{diagramme2} 
\end{figure} 


\subsection{Classe Concrète non publique}
Dans cette solution, les deux classes \texttt{PassagerStandard} et \texttt{Autobus} ne sont plus accessibles en dehors du paquetage, tout en gardant les deux interfaces déjà définies. Donc, le client ne peut plus instancier ces deux classes. Dans ce cas là, les méthodes internes ne sont plus accessibles en dehors du paquetage, même si elles demeurent avec le mot-clé \texttt{public}.

\\

Par contre, il n'est plus possible de récuperer des instances de \texttt{PassagerStandard} et \texttt{Autobus} dans la classe client. Pour résoudre ce problème, on introduit une nouvelle classe \texttt{tec.FabriqueTec} qui contient deux méthodes renvoyant des instances des deux classes concrêtes :
\begin{itemize}
\item \texttt{public static  PassagerStandard fairePassagerStandard(String nom, int destination);}
\item \texttt{public static Autobus faireAutobus(int nbPlacesAssises, int nbPlacesDebout);}
\end{itemize}

\\

Les méthodes sont déclarées en \texttt{public} pour qu'elles puissent être appelées en dehors du paquetage au niveau du code client de la manière suivante : \texttt{FabriqueTec.fairePassagerStandard(nom,destination)}.

Elles sont déclarées en \texttt{static} pour qu'elles définissent des méthodes de classe. Ainsi, on n'a pas besoin d'instancier la classe pour pouvoir accéder à ses méthodes.



\\

En définissant un constructeur qui ne fait rien et en le mettant en \texttt{private}, on garantit que la classe \texttt{FabriqueTec} ne peut pas être instanciée en dehors de la classe. De plus, pour garantir que cette classe ne va pas servir de classe de base, on ajoute le mot-clé \texttt{final} qui interdit son héritage.






%diagramme de classe solution non publique
\begin{figure}[!h]
\begin{center} 
\includegraphics[width=10cm]{diagramme3.png}
\caption{Diagramme de classe de la solution non publique}
\end{center}
\label{diagramme1} 
\end{figure} 



\subsection{Comparaison des deux solutions}
Les deux solutions permettent l'ajout de nouvelles classes concrètes \texttt{passager} ou \texttt{bus} sans modification du code, vu que toutes les méthodes vont être réalisées dans les classes concrêtes et sont soit héritées d'une classe abstraite (première solution) soit d'une interface (deuxième solution). 
Reste à préciser que la solution non publique qui utilise deux interfaces introduira à l'ajout une légère modification de code due au fait que les classes conrètes ne sont pas publiques, et donc il faudrait ajouter à la classe \texttt{FabriqueTec} des méthodes qui permettent de retourner des instances des nouvelles classes ajoutées.

\\

De plus, si les classes faussaires héritent de la classe \emph{Message} au lieu du lien \emph{a-un}, la réalisation avec les abstractions ne serait plus valide puisque l'héritage multiple du type simple (type et réalisation) n'est pas permit en \emph{java}.  

\section{Boutez vos neuronnes}
\subsection{Le contenu des fichiers compilés}

L'option \emph{-private} permet de lister les membres privés.
En fait, au niveau visibilité, elle liste au moins les membres privés. Elle liste donc tous les membres.
\\

Par ailleurs, l'option \emph{-c} permet de désassembler le code. On obtiendra donc bien un code intermédiaire (qui sera ensuite interprété).
\\

\section{Conclusion}
L'avancement lors de ce TD a été assez freiné, nous avons d'abord tenu à régler les anomalies concernant le code du TD précédent afin d'avoir une bonne base sur laquelle reposera la continuité des prochains TDs.
\\
Ce TD nous a permit de maîtriser et de réaliser l'importance de quelques concepts clés en programmation orientée objet que sont le mécanisme d'\emph{héritage} et la relation \emph{Type/sous-Type}.
\\
De plus, ce TD a introduit plusieurs alternatives à l'organisation des architectures de classes visant le respect de l'encapsulation, le masquage de la réalisation et des méthodes internes ainsi que l'ajout de futures classes concrètes sans avoir à modifier le code existant. Ainsi, il s'avère que la définition de l'architecture des classes et l'implémentation des classes de base est une étape prioritaire et fondamentale.   


\end{document}
